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Labelled Transition Systems (LTSs) are a fundamental semantic model in many areas of informatics, 
especially concurrency theory. Yet, reasoning on LTSs and relations between their states can be 
difficult and elusive: very simple process algebra terms can give rise to a large (possibly infinite) 
number of intricate transitions and interactions. To ease this kind of study, we present LTSwb, a 
flexible and extensible LTS toolbox: this tutorial paper discusses its design and functionalities. 

1 Introduction 

LTSwb (from “LTS WorkBench ”) lfl4]l is a Labelled Transition System (LTS) toolbox, allowing to define 
LTSs and processes, manipulate them, and compute relations between their states. Its main features are: 
genericity. LTSwb does not require LTSs and processes to have specific state/label types. This allows 
to semantically reason on different process specifications: for example, it allows to study whether 
a CCS process lfl2l is a semantic refinement of a session type lITOll (as in flU), or whether it can 
correctly interact with a service whose specification is given as a Communicating Finite-State 
Machine (CFSM) H; 

reusability. LTSwb is built upon an underlying relational calculus, whose operators allow for relation 
filtering, sequencing, parallel composition, etc.. Such operators are fully generic, and can be reused 
e.g. to implement different process calculi without having to redefine similar operators each time; 

laziness. Very large, and even infinite-state LTSs and processes are managed transparently: states and 
transitions are only generated upon request. This allows to mitigate state space explosion problems, 
and to explore and filter out (finite) parts of infinite LTSs arising e.g. with recursion, parallelism, 
unbounded communication buffers, etc. 

LTSwb is a Scala [fl3l library. The choice of Scala is motivated by the desire of a functional program¬ 
ming language with an advanced type system, and an access to the vast landscape of libraries available on 
the Java VM; moreover, Scala’s lazy values allow for controlled lazy evaluation in an eager language 
— a mix which we found helpful for our implementation. LTSwb can be used directly on the interactive 
Scala console: unless otherwise noted, all the examples on this paper can be replicated therein via simple 
cut&pasting. 

2 LTSs, processes and asynchrony 

An LTS is a triple (£, A, 31) where £ is the set of states, A is the set of labels, and 3? C (£ x (A x £)) is 

the transition relation. A process is a pair (L, a) where L is an LTS and <7 is one of its states. The process 

t 

transition (L, a) —> (L, cr) holds iff (a, (£, a')) is in the transition relation of L. 
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In sections 2.2 


to 2.5 we show how LTSwb processes can be created (by extracting them from some 
LTS) and manipulated, and how the framework can be extended. But first, in Section [2TT| we give some 
intuition about the underlying relational calculus. Note that such a section is not strictly necessary to 
follow the rest of this tutorial paper, and it is possible to directly jump to Section [2~2] 


2.1 Under the hood: a relational calculus 


In this section we sketch (and give reasons for) the relational calculus at the core of LTSwb, by showing 
the correspondence between relational sequencing and the well-known sequencing operator provided by 
several process calculi. We first need to introduce some more notation: 


• the set of continuations of a process after transition £ is 


(M(4 = {(L ,//) 


(L,p) A (L,//)|; 


• given a relation (R C A x T, the image of 8 under (R is the set 1R(5) = {y | (5, y) G fR}. 


Now, say that we want to study the behaviour of processes written in a calculus C, equipped with the 
usual sequential composition operator (p seq q ) , with LTS semantics inductively defined by the rules: 


i , 
P~> P 


p-fr q 4 f 


( p seq q ) 4 (// seq q ) ( p seq q ) 4 ( p seq </) (where p-fy iff fl£,p' .p 4 p ) 


We can observe that such a definition is independent from the syntax of p, q and l, and is therefore 
adaptable to different process calculi. Such a definition is also meaningful if, for example, p,q are 
state-transition-state traces extracted from an execution log: their sequential execution would be defined 
in the same way. Can we implement such a composition upon a reusable syntax-independent foundation? 

One way to address such a question is to define sequencing at an underlying relational level. Let 
3?i C (£i x (Ai x rj)) and (R 2 C (£ 2 x (A 2 x £ 2 )). The sequencing ofJi\ and fR 2 is the relation 

£ (4ix£ 2 )x((A 1 UA 2 )x(£ , 1 x£ , 2 ))) 

inductively defined by the following rules (notice the similarity with the seq rules above): 

(p,(l,;/)) eft! Kt(p)=0 (4(14)) £ ft 2 

(ip,q), (4(44)) e &t ((p,4> (4 (p,4))) e ^ 0^2 

We can equivalently define the sequencing of (Ri and fR 2 by defining the image of (p.q) under T] : 1R 2 : 

/ \ , . f{(^,(y^))|(^4) (p)} if ^Ri (p) f ® 

(0h;X2)((p,q)) = { 

v 7 [{(£,{p,4))\(l,4) €3l 2 {q)j otherwise 

We can now “lift” the sequencing operation from the relational level to the LTS level. Let Li = 
(£i,Ai,3?i ) and L 2 = (£ 2 ,A 2 ,(R 2 ). The sequencing of Li and L 2 is: 

Li ;L 2 = ^ £1 x £ 2 , Ai U A 2 , fRi;(R 2 ) 

Finally, we can further lift sequencing to processes. The sequencing of processes (Lj ,p) and (L 2 , cy ) is: 

(L b p) ;(L 2 ,<7) = ^Li;L 2 , (p,<?)) 









The LTS WorkBench 


and we can observe that the process (Lj ,p) ; (Lo.t/j performs the transitions of p in Li, followed by those 
of cj in L 2 . 

We can now return to our calculus C, with its sequential composition ( p seq q) . Let L c = 
(ic.Ac.^c) be the LTS inhabited by C’s processes. We want the transition diagram of ( p seq q) in 
L c to be observationally indistinguishable from that of the sequenced processes (L c,p) ; (hc,q), i.e.: 

(h c ,(p seq q)^j = (L c ,p) ; (h c ,q) (where =* is transition diagram equality, up-to node renaming) 


In other words, we want the continuations of (p seq q) after transition £ to be isomoiphic to the 
continuations of (L c,p) ; (Lf-.r/j after £. We can obtain this by requiring: 


(l-c, (p seq q)J(£) 


|^L c ,(p seq q)') 
{(l c,(p seq q')'j 
{(l-c, Cp' seq q')J 


(L c ,p) ;(L c ,q) € ((L c ,p) ;(L c ,g))(£)} 
(pW) e (iL c -Xc,{p,q)^W} 

OW) e (^c;^c) {(p,q))(£)} (i) 


Since (by definition) (Lc, ( p seq q))(£) = {(L c,p") I P" € %c((p seq q)) (£)}, we must also have: 

(h c ,(p seq q)^j(£) = { (L c ,(p' seq cj)) \ (p seq cj) eJt c {(p seq q))(£)} (2) 

Therefore, from ([T]) and Q we have that the image of ( p seq q) under the transition relation IRc must 
be isomoiphic to the image of (p,q) under the sequenced relation Jlc: Lc : 


%c((p seq q)) = {(£,(// seq cj)) (£, ,<j)) G {(p,q )) } 


This last equation tells us that the transitions of (p seq q) in Lc can be inductively defined upon 
the transitions of (p,q) in Lc;Lc simply by providing such an isomorphism — which is just a syntactic 
deconstruction/reconstruction of the former into/from the latter. Hence, the syntax-independent relational 
sequencing operator can be reused (with minimal syntax-dependent additions) to define the sequencing 
operator at the process calculus level. 

This theoretical foundation is the heart of the implementation of LTSwb: all the LTS-level and 
process-level operators described in the rest of this tutorial (including the more complex ones, such 
as parallel composition, asynchronous transformation and filtering) are implemented upon underlying 
syntax-independent relational operators. 


2.2 From LTSs to processes 

In LTSwb, a finite LTS can be defined with the LTS constructor, by enumerating the state-(label-state) 
triples which compose its transition relation. For example: 

val 11 = LTS ( List ((0, 1)), (1, 2)), (2, 3)), (2, 1)))) 

val 12 = LTS ( List (("pi", ("!a", "p2")), ("p2", ("?b", "p3")), ("p2", ("?c", "pi")))) 

The types of 11 and 12 are (respectively) FiniteLTS [Int .String] and FiniteLTS [String, String] : 
i.e., they are finite-state, finite-branching LTSs where states are Integers (resp. Strings), and labels are 
Strings. The methods 11 .toDot and 12.toDot return their graphs (shown on the left of Figure |2.1[ ). 
The I I I operator on LTSs returns the LTS whose states correspond to the parallel composition of its 
arguments’ states, provided that the labels have the same type: Figure |2Tj (on the right) shows the diagram 










A. Scalas, M. Bartoletti 


89 



of (11 I I I 12) .toDot. Such a composition is performed lazily, thus avoiding (or delaying) state space 
explosion problems: the actual combinations of LTS states are generated only upon request. 

A process can be simply retrieved from an LTS through one of its states. For example: 
val pi = 12.process("pl") 

In this case, we have that pi has type FiniteProcess [String,String] (i.e., a finite-state, finite- 
branching process where states are Strings, and labels are Strings as well). As one might expect, 
pi. state has indeed value "pi". Moreover, pi. Its is 12 — i.e., the LTS inhabited by pi. 

A process can be queried for its enabled transitions. In our example, pi .transitions has type 
FiniteSet [String] , and value Set ( " ! a" ) . We can now let: 

val pla = pl("!a"); val p2 = pla.iterator.next 

where pla is the FiniteSet of continuations of pi via transition "! a". In our example, pla contains a 
single element, i.e. the process corresponding to state "p2" of 12: such a process is retrieved via pla’s 
iteratoiQ and assigned to p2. As expected, p2. transitions has value Set ("?b" , "?c") . 

Processes can be composed in parallel, similarly to LTSs (as shown above). Let: 
val pOl = 11.process(O) ||| pi 

plO has type FiniteProcess [(Int, String), String] (i.e., each state is a pair of (Int .String), 
while labels remain Strings). The transitions of pOl are those of the LTS state (0 ,pl) in Figure [271] in¬ 
deed, the same process could have been extracted with (11 | | | 12).process((0, "pi")), and pOl.Its 
is 11 I I I 12. 


'Note that the same process can also be retrieved via 12 .process ("p2"), as we did for pi above. 
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2.3 CCS processes 

LTSwb implements CCS, which is the infinite LTS whose states are CCSTerms, labels are CCSPref ixes, 
and the (infinite) transition relation corresponds to the CCS semantics. Processes can be extracted from 
CCS as above, i.e. with CCS .process (s) (where s is a CCSTerm), or letting LTSwb parse terms from 
strings: 

val ccsl = CCS .process("rec(X) (!a.(?b + ?c.X))") 
val ccs2 = CCS ("?a. (t.!c.?a.!b + t.!b) ") 

The type of ccsl and ccs2 is FiniteBranchingProcess [CCSTerm, CCSPref ix] —i.e., they are finite- 
branching (but not necessarily finite-state) processes whose states are CCSTerms, and whose transition 
labels are CCSPref ixes. Note that ccsl has, intuitively, the same transitions of process pi defined 
earlier: for example, ccsl. transitions is Set(!a). There is, however, a difference: the CCS LTS 
distinguishes CCSPref ixes among input, output and internal actions (respectively: ?a, !a,r), and this 
additional information (which is not present for the simple string labels of process pi above) is exploited 
by the | I I operator to let two parallel CCS processes synchronise. For example, let: 

val ccsl2 = ccsl ||| ccs2 

Here, ccsl2 has type FiniteBranchingProcess [(CCSTerm, CCSTerm),CCSPref ix] , and the value 
of ccs 12.transitions is Set(?a , !a , t). As expected, the T-transitionis generated by the synchron¬ 
isation on a — and indeed, as shown in Figure | at| ccs12(t) return^} 

Set ( ( (?b + (?c.rec(X)(!a.(?b + ?c.X)))) , (t.!c.?a.!b + t.!b) ) ) 

The synchronisation mechanics are parametric at the LTS level — and in particular, they are regulated by 
two methods: 

• LTS. syncpdl, 12) is a predicate telling whether labels 11 and 12 can synchronise (its default 
implementation is false, thus only catering for interleaved executions, as shown in Section |T2] ); 

• LTS. syncLabel (1) returns the new label emitted when synchronising on label 1 (the default 
implementation is vacuous, since LTS. syncpO is false by default). 

Further details about the implementation of these methods in the case of CCS are given in Section [23] 

2.4 From synchronous to asynchronous semantics 

If p is an instance of Process (which is the main abstract class common to all LTSwb processes), then 
p. async is a new process obtained by pairing p with an empty FIFO buffer, represented as a List. LTSwb 
performs this transformation in a general, purely semantic fashiorj^J each output label of p is appended to 
the buffer (with an internal transition), and the head of the buffer enables a corresponding output transition. 
This change is transparently reflected in the values returned by p. async. transitions. For example: 

val ccsla = ccsl.async; val ccs2a = ccs2.async 

ccsla and ccs2ahave type FiniteBranchingProcess[(CCSTerm,Seq[CCSPrefix]),CCSPrefix] 
(i.e., each state pairs a CCSTerm with a sequence of prefixes). The difference between ccs2 and ccs2a is 
shown in Figure [L2| it can be seen that, for example, the first !c transition of ccs2 becomes a z transition 
(with buffering) in ccs2a, and the head of the buffer is later consumed with a !c transition. Note, however, 

2 Note that ccsl2(r) and its return value have been slightly edited for clarity, and thus are not valid Scala code. 

3 Indeed, such an operation is performed at the LTS level: if 1 is an LTS, then 1 . async is the LTS with l’s states paired with 
a buffer; if s is a state of 1, then 1. async .process((s, List ())) is equal to 1 .process (s) . async. 
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Figure 2.2: Outputs of ccs2.toDot() (left) and ccs2.toDot() (right). 

that there is an important difference between ccsl and ccsla: while the former has a finite number of 
states, the latter has infinite states, due to the presence of recursion and unbounded buffers (the difference 
can be seen in Figure |A2| ). This is not a problem per se, because, as remarked above, LTSwb ensures that 
process transitions are expanded “lazily”. Pairing a finite processes with an unbounded buffer reminds 
of Communicating Finite State Machines (CFSMs) (2) — and indeed, a CFSM-like interaction (modulo 
the different naming of labels) can be modeled with the composition ccsla I | | ccs2a, by filtering the 
states reachable via internal moves and synchronisations: the resulting finite transition diagram is shown 
in Figure [A3] (note that the “unfiltered” transition diagram of ccsla I I | ccs2a is infinite). 

2.5 Adding new process calculi 

LTSwb has no “hardwired” notion of process calculus. A new process calculus with labelled semantics can 
be added to the framework in four steps: (i) define (or possibly reuse) a class L for its labels, (ii) define 
a class T for its terms, (iii) define a transition relation R by deriving the class Relation3 [T, L, T] , and 
(iv) suitably derive the abstract class LTS, using T and L respectively as state and label types (specifying 
which labels are input/output/internal, and how they synchronise), and R as transition relation. This very 
approach has been followed for implementing CCS under LTSwb, as sketched below: 

(i) the base (abstract) class for CCS labels is CCSPref ix, with one derived class for each concrete 
label type: CCSInPref ix, CCSOutPref ix, and CCSTau; 

(ii) the base (abstract) class for CCS terms is CCSTerm, with one derivative for each syntactic produc¬ 
tion: CCSNil (terminated process), CCSSeq (prefix-guarded sequence), CCSPlus (choice), CCSPar 
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(parallel), CCSRec (recursion), CCSVar (recursion variable), CCSDel (delimitation). Such classes 
represent the CCS abstract syntax tree, and they are instantiated by the CCS parser; 


(iii) the CCS semantics is implemented in the CCSSemantics singleton class. Its core method is 
apply (s: CCSTerm) , which returns the image of s, i.e. a binary Relation [CCSPref ix,CCSTerm] 
containing the label-state transitions arising from s. For example, is s is a CCSNil instance, the re¬ 
turned relation is empty; if s is CCSSeq(pfx:CCSPrefix, cont: CCSTerm), the returned relation 
only contains the pair (pfx, cont) , and so on. The other (more complex) cases exploit LTS-level 
or relational-level operators already provided by LTSwtj^j for example, if s is CCSPlus (terml, 
term2), the return value is CCS. apply (terml) I CCS.apply(term2) , where | is the union of 
the relations returned by invoking apply () on the two subterms: as a consequence, in the resulting 
relation, a transition from terml leads to a continuation which neglects term2, and vice versa — 
as expected by the standard behaviour of the CCS choice operator. Instead, if s is CCSPar (terml, 
term2), the returned relation is created by dire ctly reus ing the syntax-independent, LTS-level 
implementation of I | | described in Sections 2.2 and i 


2.2 


(iv) finally, the CCS LTS is implemented in CCS, which is a derivative of FiniteBranchingLTS [CCSTerm, 
CCSPrefix]. The LTS. syncp(ll, 12) method is overridden so that it returns true whenever, for 
some string a, 11 == CCSInPref ix(a) and 12 == CCSOutPref ix (a) (or vice versa)', moreover, 
the LTS. syncLabel (1: CCSPref ix) method is overridden so that it returns CCSTauPref ix() 
(i.e., each synchronisation causes the emission of a T-prefix). 


With this approach, the CCS-specific code is mostly necessary for parsing terms, while the semantics 
of the operators is factored into several syntax-independent classes; moreover, the implementation of 
CCS. process () and all the operations on CCS processes (e.g., Ill, .toDotO, . async,. ..) are provided 
by the base abstract classes of LTSwb. 

We conclude this section noticing that, additionally to standard CCS syntactic constructs, LTSwb 
offers semantic operators allowing e.g. process filtering (as we did for T-reachable states in Section [2~4j >, 
and general sequencing: for all processes pi, p2 with the same label type, pi. seq(p2) returns a process 
which behaves as pi until it terminates, and then behaves as p2. These semantic methods can be leveraged 
through the LTSwb API, on all LTSs and processes; if one wants to implement an additional process 
calculus with such filtering/sequencing capabilities at the syntactic level, then it is possible to simply 
reuse the underlying semantic facilities, without reimplementing them. 

Finally, we stress that, if two processes (notwithstanding their LTS) share the same label type, then 
they can synchronise, and their relations can be studied as shown in Section [3] 


3 Behavioural relations 

One of the goals of LTSwb is implementing and studying semantic relations, without syntactic limitations. 
LTSwb currently implements (bi)simulation, and some variants of progress (4) and I/O compliance HI, i.e. 
notions of “correct” interaction between processes. We exemplify the latter (the others are used similarly). 


3.1 Experiments with I/O compliance 


Intuitively, two processes p,q are I/O compliant iff the outputs of p are always matched by the inputs of q 
(and vice versa), even after synchronisations and internal moves. The IOCompliance .build() method 


4 

5 


The theory beyond such operators is sketched in Section 


2.1 


Such LTS operators are based on a relational parallel composition operator: the principle is the same sketched in Section 


2.1 
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val alice = CCS(" !aCoffee.?coffee.!pay + !aBeer.(?beer.!pay + ?no.!pay)") 

val bartender = CCSO'rec (Y)(?aCoffee.!coffee.Y + ?aBeer.(!beer.Y + !no.Y) + ?pay)") 

val ab = IOCompliance .build(alice, bartender) 

val aba = IOCompliance .build(alice.async, bartender.async) 


Listing 3.1: Alice and bartender example, from lUl . 


val aliceH = CCS (" !aCoffee.(?coffee I !pay)") 

val bartenderL = CCS("rec (Y)(?aCoffee.!coffee.Y + YaBeer.(Ibeer.Y + !no.Y) + ?pay 

+ t . rec(Z)(?aCoffee.!coffee.Z + ?aBeer.!no.Z + ?pay))") 
val aHbL = IOCompliance. build(aliceH, bartenderL) 
val aHbLa = IOCompliance .build(aliceH.async, bartenderL.async) 


Listing 3.2: Another example from |T|: Alice tries to grab the coffee and pay at the same time. 

takes two FiniteBranchingProcess instances, and returns an Either object whose Right value is a 
finite I/O compliance relation. If p.q arc not I/O compliant, the returned Left value is a counterexample, 
i.e. a pair of non-I/O compliant states. Consider the first call to IOCompliance ,build() in Listing 
EES since alice and bartender are I/O compliant, ab’s Right value is an I/O compliance relation 
containing the pair (alice, bartender); the same holds for aba, built on the asynchronous versions of 
the two processes. 

Listing [3T2] shows more examples. The second call to IOCompliance .buildO is successful and 
returns Right, with an I/O compliance relation containing the asynchronous processes. The first call 
to IOCompliance.buildO, instead, is not successful, and aHbL is the Left value below (edited for 
clarity): 

Left ( (Tcoffee I !pay ), 

(!coffee.rec(Y)(?aCoffee.!coffee.Y + ?aBeer.(Ibeer.Y + !no.Y) + ?pay 

+ t.rec(Z)(?aCoffee.!coffee.Z + ?aBeer.!no.Z + ?pay))) ) 

The problem is that, after synchronising on aCoffee, aliceH and bartenderL reach the states inside 
Lef t (■ ■ •) , where the !pay transition of the former is not matched by a (weak) ?pay of the latter. 


3.2 Adding new compliance relations 


Both IOCompliance and Progress are derivatives of an abstract, reusable class called Compliance. 
Intuitively, 1R is a coinductive compliance relation iff, whenever (p,q) £ A. then: 

(i) pred(p ,q) holds; (where pred is given as a parameter) 

(ii) p —>• fi and q —> and l,l can synchronise implies (// ,c/) £ (R; 

(Hi) p => p' and q => c{ implies ip'■c() £ Jl. (where => represents 0 or more internal moves) 
Compliance implements the .buildO method according to the definition above: given ( p,q ), it ensures 


that a class-specific predicate pred holds for p,q (as per clause (i) I, and then checks their reducts after 


synchronisation or internal moves (as per clauses (ii) and (iii) I. Compliance .buildO terminates when 
either no more states need to be checked, or pred is false: in the latter case, it returns a counterexample, as 


seen in Section 3.1 Progress, IOCompliance and their variants are implemented by just changing pred, 
and new coinductive compliance relations can be added in the same way: e.g., the “Correct contract com¬ 
position ” from |3) (Def. 3) can be added by defining pred (p ,q) as (p I \ I q) . wbarbs . contains (/) 
(where . wbarbs is the Set of weak barbs of a process, and / is a label denoting success). 
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Note that Compliance .build() only implements a semi-algorithm: hence, the method may not 
terminate if one of the processes under analysis is infinite-state — and in particular, if it can reduce, through 
internal moves, to an infinite number of distinct states. In such a situation, LTSwb may need to construct 
an infinite compliance relation, with an infinite search for states violating pred. Our Alice/bartender 
examples are infinite-state, but do not generate infinite internal moves, and the semi-algorithm terminates. 
The risk of non-termination could be simply avoided by leveraging the types provided by LTSwb: for 
example, by only calling Compliance .buildO on FiniteProcess instances (e.g., through a simple 
wrapper). This would be a sufficient (but not necessary) condition ensuring the termination of the method, 
albeit sacrificing cases such as the ones illustrated above. By letting Compliance .buildO also accept 
FiniteBranchingProcess arguments, LTSwb allows to experiment with behaviours for which the 
termination of the method is not (yet) clear, or follows by some properties which are not easily captured 
by the type system (e.g., the way inputs/outputs are interleaved in the Alice/bartender example). 


Verifying relations. LTSwb also implements the method Compliance. check(). Given an instance 
r of some Compliance-derived relation, r.checkQ is true when each pair of states in r actually 
respects pred according to clause [(7)] above, and r contains all the pairs of states required by clauses (ii) 


and (iii) Consider e.g. Listing |34~[ ab is a Right value, and ab.right .get. check() is true. This 


also holds for aba, and aHbLa from Listing [T2] It is important to note that Compliance .buildO and 
Compliance. check() are implemented separately: the latter is intended as an independent verification 
method, also for relations which are defined “by hand” (i.e., directly as finite sets of pairs of states) without 
resorting to their own .buildO methocj^] For example, we can instantiate a Progress relation from an 
existing relation: 


val aHbLaProg = Progress (aHbLa.right.get) //Recall: aHbLa is an incompliance rel. 

and in this case aHbLaProg. check() holds — i.e., notwithstanding its type, aHbLa is also a progress 
relation. Under this framework, if a new compliance relation is implemented as explained above (i.e., by de¬ 
riving the Compliance class and providing a suitable class-specific pred), then synthesis ( .buildO) and 
verification ( . checkO) are obtained “for free”. A similar framework is also in place for (bi)simulation. 


4 Conclusions and future work 

In the current (early) stage of development, LTSwb offers a flexible and extensible platform allowing to 
define generic LTSs and processes, explore their (finite or infinite) state space and study their (bi)simulation 
and compliance relations. It offers general, syntax-independent operators for manipulating LTSs and 
processes, on which specific process calculi can be implemented. 

The most similar tool, albeit more CCS-centric, is O, whose development stopped around 1999: 
hence, its obsolete dependencies and restrictive licensing terms make it very difficult to use and improve. 
Another related tool is LTS Analyser E2 — which is limited to finite-state processes; moreover, its 
development stopped around 2006, and its source code is not available. 

It is possible to find some similarities between LTSwb and the Process Algebra Compilers proposed in 
the ’90s j5|: LTSwb can be seen as a semantic backend on which a process calculus can be “compiled” by 
suitably deriving some classes, and letting the parser instantiate them — as sketched in Section [23] On 
the one hand, this approach makes the parser quite integrated into LTSwb, and not very suited for different 
backends; on the other hand, the tight integration allows to use parser combinators, thus obtaining easily 
maintainable, well-typed parsers. 

6 When debugging is enabled, LTSwb runs . checkO on each relation created by Compliance .buildO, to test its code. 








A. Scalas, M. Bartoletti 


95 


Beyond representing and manipulating LTSs and processes, LTSwb also allows to explore them — 
not unlike well-established model checking tools like mCRL2 Q and CADP [[81. Besides being much 
smaller and less mature than such tools, LTSwb also has a different goal (being a framework rather than an 
application) and tries to keep a more semantic foundation, in that it does not depend on (nor privileges) 
specific process languages. One intended usage scenario of LTSwb is the following: suppose you want to 
introduce a new behavioural relation (say, I/O compliance), and you want to study it on some process 
algebra (say, asynchronous CCS), or on some processes whose specification is provided directly as a set of 
state-label-state triples (e.g., from some industrial case study). One can achieve these goals by extending 
the Compliance class, and applying it on LTSs and processes, as summarised in the paper. An alternative 
way would be that of (1) encoding asynchronous CCS or the given state-label-state triples into the process 
calculus and LTSs accepted by mCLR2 or CADP and their tools (proving that such an encoding is correct), 
and (2) encode I/O compliance into e.g. a fa -calculus formula (and, again, prove that such an encoding is 
correct). Both alternatives are possible; however, we think that for the scenario sketched above, the LTSwb 
framework allows users to obtain quicker results. We also believe that the relational calculus introduced in 
Section |2T] allows for greater flexibility and reusability, e.g. when carrying out experiments which require 
to combine LTSs and processes, or implement some process calculus. 

Future work on LTSwb includes the addition of more relations, with a “reusable” approach to synthesis 
and verification similar to the one adopted for Compliance and (bi)simulation. We also plan to fully 
formalise the relational calculus summarised in Section [2~j~[ and study its properties. Moreover, we plan 
better support for multiparty interactions (currently provided via the PCCS calculus, not discussed here) 
and richer process calculi with time and value passing. We also plan to integrate LTSwb with Gephi ||9), 
thus providing a better user interface with interactive exploration of large transition diagrams. 
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A Figures 



Figure A. 1: Output of ccs!2. toDot (). 
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Figure A.2: Output of ccsl.toDot () (top) and ccsla.toDot(maxDepth=Finite(4)) (bottom). 
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Figure A.3: Output of (ccsla III ccs2a) . filter (1 => 1. isTau) ,toDot(). Note that T- 
transitions generated by synchronisations cause the reduction of buffers — i.e., the output at the head of a 
buffer is consumed by an input of the other process. 































